"פיתוח ממרס אבטחה ממאדים" )אבטחת מידע בפיתוח מערכות ב- )IT

Transcription

1 סיכום מפגש שולחן-עגול "פיתוח ממרס אבטחה 1 ממאדים" )אבטחת מידע בפיתוח מערכות ב- )IT עורכים: פיני כהן ושחר גייגר מאור 1 אפשר גם אבטחה ממרס ופיתוח ממאדים...

2 תוכן עניינים תמצית מנהלים...2 תהליך פיתוח סוגיות "אידאלי" מהיבט אבטחת מידע...3 בעייתיות...3 Security.Net אבטחה ברשת... 5 שיפור תהליכי עבודה... 9 הפיתוח הוא של השותפים\מוצרים, אבטחת המידע של הארגון נאמן אבטחת מידע...12 תקציב אבטחת המידע בפיתוח דוגמאות לטכנולוגיות בשימוש...15 אבטחת מידע באקדמיה טיפים והמלצות לשיפור יחסי אבטחת המידע/פיתוח...17 נספח מיוחד התייחסות ספקים לנאמר במפגש...18 התייחסות חברת...18 F5 התייחסות חברת...18 IBM התייחסות חברת 19...Matrix התייחסות חברת...19 Ness התייחסות חברת 20...Tescom תמצית מנהלים פיתוח מערכות הוא אחת מנקודות הקשר המעניינות ביותר בין עולם הפיתוח לעולם אבטחת המידע. בעוד שאנשי הפיתוח ניצבים מול אתרים טכנולוגים מורכבים, לו"ז קשוח ועומס עבודה טבעי, הם נדרשים לעמוד לא פעם גם באתגרים הנוגעים להיבטי אבטחת המידע של המערכת. אנשי אבטחת המידע, לעומתם, מוצאים עצמם, לא פעם, ממודרים מפרוייקטים בשל "החשש מהצקות" שלהם למנהלי הפיתוח ועיכוב העליה לאוויר. אחריות מנהלי אבטחת היא לשמור על סטנדרטים גם בנושאי פיתוח ואתגר זה לא פשוט בכלל. המוטיבציות של שני הגורמים המקצועיים שונות לגמרי במקרים רבים והבדלים אלה עלולים להביא לחיכוכים, וסיכונים מיותרים. מטרת המפגש הנ"ל היא לתאר את נקודות החיכוך העיקריות בין גופי הפיתוח לאבטחת המידע ולנסות למצוא נקודות לשיתוף פעולה.

3 דוגמה בולטת לפערים בין שני הגופים הוא המונח.SDLC מונח זה נפוץ בשימוש על ידי שני הגופים אולם הפירוש הוא שונה בתכל ת!י SDLC אליבא-דה אנשי הפיתוח משמעו.Software Development Lifecycle 2 אולם לפי אנשי האבטחה משמעו בין הצדדים..Secured Development Lifecycle 3 כלומר, אין שפה משותפת במפגש השתתפו נציגים מגופי פיתוח וניהול פרוייקטים לצד אנשי אבטחת מידע במספר ארגונים גדולים ובינוניים בישראל. רוב המשתתפים מגיעים מהסקטור הממשלתי והפיננסי, אך היו בו נציגים ממגזרים נוספים. מצ"ב סיכום עקרי הדברים שעלו במהלך המפגש. במפגש עלו נושאים מהותיים שתומצתו בסיכום כפי שעלו. אין בסיכום זה המלצה גורפת ללקוחות אלא מתן פרספרטיבה והצגה של ההתלבטויות שעלו במפגש, כלומר "מהשטח". תהליך פיתוח "אידאלי" מהיבט אבטחת מידע לרוב המשתתפים ברור הצורך בשילוב אבטחת המידע בתהליך הפיתוח כאשר שילוב זה אמור לכלול במצב אידאלי: ערוב של אבטחת מידע בכל שלבי הפרוייקט - החל בשלב הייזום )לפעמים עוצרים כבר בשלב הזה פרוייקט בגלל אי יישימות או סיכון אבטחתי(, המשך בשלב הניתוח, הקידוד ועד השלבים השונים של הבדיקות. כלי בדיקות אוטומטיות במהלך הקידוד. אידאלית הקוד נבדק כל הזמן\כל יום. ביצוע סקר קוד ייעודי מעמיק בשלב הבדיקות בנושא של אבטחת מידע. בדיקות 4 "white-black-gray" ( PT ראו ביאור בהמשך( על קוד בשל שעבר אחד לפחות. ישנם ארגונים אשר מבצעים PT גם בייצור )כלומר QA PT שני(..5.6 נהלים של אבטחת מידע לפיתוח "עשה ואל תעשה" בכל טכנולוגיה. הכשרות בסיסיות של כל המפתחים והכשרות מתקדמות יותר למפתחים שהנם "נאמני אבטחת מידע". סוגיות בעייתיות עם זאת, מעטים הארגונים שמצליחים להגיע למצב אידאלי זה וגם שתוארה ישנם מספר סוגיות בעייתיות. להלן התייחסות למספר סוגיות מסוג זה: בתמונה האידאלית פרוייקטים לא מתוכננים אשר לא תמיד מגיעים לידיעת גוף אבטחת המידע. וגם Penetration test 2 4

4 נציג מארגון פיננסי העלה את הקושי הזה כקושי מרכזי בליווי פרוייקטים מצד אבטחת המידע. בארגון זה יש קושי בהגדרה של מה זה בדיוק "פרוייקט". במקרים שלא מוגדר "פרוייקט" אין אבטחת מידע מתחילת התהליך ומבחינתם של אנשי הפיתוח המיזם "סובל" פחות מבירוקרטיות. דוגמא לכך היא שינוי מסויים שהתבקש במערכת מסויימת בארגון. כחלק מהשינוי ניתנו הרשאות גישה לנתונים רגישים. בגלל שהשינוי לא הוגדר "פרוייקט" הוא חמק מעיניהם של אנשי אבטחת המידע והם גילו את השינוי רק בדיעבד. האם המפתחים רשאים לראות נתונים כאלה ואחרים תוך כדי תהליך הפיתוח? האם בכלל ניתן לבצע פיתוח בלי לראות את הנתונים כלל? מובן שמפתחים )ובודקים( ירצו לעבוד על נתונים קרובים ככל הניתן לנתוני האמת. אחד הפתרונות המוצעים על ידי אנשי אבטחת המידע ומוזכרים ברגולציות כגון PCI 5 הם פתרונות לערבול נתונים. ערבול נתונים מלא הוא משימה כמעט בלתי אפשרית, לדעתם של חלק מהנוכחים, בגלל אוסף המערכות והקשרים המורכבים בין הנתונים. פערים טכנולוגיים: לטענת אנשי הפיתוח, אנשי אבטחת המידע חוסמים לעתים שימוש בטכנולוגיות מסויימות בגלל חשש מוגזם או בגלל חוסר ידע מספק. לדוגמא: לקוח תאר מצב שבו אסרו עליו להשתמש ב- AJAX או. jquery אנשי אבטחת המידע מנסים לעתים לנתב את הפיתוח לטכנולוגיות מוכרות להם כדי שיוכלו להכיר טוב יותר את תהליכי הפיתוח ולנטר אותם. פרוייקטים בעייתים במיוחד הם פרוייקטי.Main-Frame תחום ה MF מתאפיין ברמת מומחיות גבוהה מאוד וידע אשר לא תמיד קיים ברשותם של אנשי אבטחת המידע. פיקוח על פרוייקטים אלה מאוד קשה באופן טבעי אם כי נחשב ברמת סיכון נמוכה יחסית. קוד שמתקבל מגורמי צד שלישי. אחד הארגונים תאר מצב שבו התקבלה בארגון אפליקציה שפותחה על ידי בית תוכנה קטן מאוד )אפליקציה בתחום רשתות חברתיות תחום המטופל על ידי אגף השיווק( שהמרחק בינו לבין פיתוח במתכונת SDLC גדול מאוד. בגלל אופי הארגון והאיומים, נדרש בית תוכנה זה לעמוד בדרישות הפיתוח של.SDLC דרישה זו האריכה את זמן העליה לאוויר של קמפיינים מסויימים פי 6 מהמתוכנן )!!(. במובנים עסקיים מדובר על מחיר גבוה שהארגון שילם כדי לשמור על סטנדרטים גבוהים של אבטחת מידע. אולם בארגונים אחרים עלתה תמונה הפוכה. במקרה אחר סופר כי בעבר נמצאו מערכות עם לקויים וחולשות אבטחתיות ונדרשו תיקונים, אולם בשום מקרה לא ירדה מהאוויר מערכת / 5

5 בשל ליקויי אבטחה שנמצאו בה. ישנם מקרי ביניים שבהם מעלים מערכת עם בעיות מבחינת אבטחת מידע אך מעדכנים את גוף ניהול הסיכונים בארגון. ההבדלים בין סביבת הבדיקות והפיתוח לבין סביבת הייצור. נושא ה"סביבות" הוא 6 נושא בעייתי במספר רב של מובנים. הקושי העיקרי בהקשר של אבטחת מידע הוא העובדה ששרתי הייצור מוקשחים יותר משרתי הפיתוח\בדיקות. נקודה זו מביאה לכך שפונקציונליות שעובדת בפיתוח\בדיקות עלולה לא לעבוד בסביבת הייצור. לטענת מספר משתתפים בדיון, סביבת הבדיקות אמורה להיות שונה מסביבת הייצור כדי לאפשר Debug טוב יותר )לדוגמא: לקוח אינו מאפשר יכולת של File Export\Import של SPS-MOSS בייצור אך כן מאפשר זאת בפיתוח ובבדיקות(. Security.Net אבטחה ברשת "בשבילי זה,Bug בשביל איש אבטחת מידע זה "Backdoor הציטוט למעלה מתמצת בצורה טובה מאוד את הבדלי הגישה בין גופי הפיתוח לאנשי אבטחת המידע ברוב הארגונים בישראל. נציג אבטחת מידע בארגון ממשלתי סיפר על ניסיון שלהם להכניס את היבטי אבטחת המידע כבר בתהליך הייזום של כל פרוייקט חדש. גוף אבטחת המידע בארגון זה שייך לאגף הביטחון. לקח להם הרבה מאוד זמן להצליח להיות מעורבים בפרוייקטים בצורה טובה ולהוריד את החיכוכים. הם כתבו טופס מיוחד שיש למלאו על ידי מנהלי הפרוייקט ולהגישו לאנשי אבטחת המידע ולאשר את המשך הפרוייקט ביחד איתם. השאיפה בארגון זה היא להגיע לשיתוף פעולה טוב בין הגופים: "להיות חלק ממחזור הפיתוח ולא נטל". המצב בארגון זה נחשב לטוב מאוד בראיה של איש אבטחת מידע: אין כיום פרוייקט אינטרנטי שעולה לאוויר ללא אישור שלהם. במקרה מסויים "החזירו פרוייקט חצי שנה אחורה" בגלל ליקויי אבטחת מידע שלא דווחו כהלכה לגורמי האבטחה בארגון. מנהל אבטחת מידע בגוף פיננסי סיפר כי אחד היתרונות הגדולים של גוף פיננסי הוא הרגולציה. הרגולציה מסדירה במובנים רבים את נהלי העבודה ומקלה את החיים בראיה אבטחתית. ברוב המקרים אנשי אבטחת המידע מעורבים כבר משלב הייזום ועד תחזוקת פרוייקטים באוויר. 6 על כך שולחן עגול בהמשך השנה

6 בגלל הרגולציה הארגון יכול להרשות לעצמו להחזיק מספר אנשי אבטחת מידע עם התמחות בעולם האפליקטיבי. אנשים אלה נותנים שירותי ערך מוסף לגופי הפיתוח ואף כותבים בעצמם קטעי קוד בעייתיים במידת הצורך. מדובר על צוות )"אבטחת מידע אפליקטיבית" בדומה ל- DBA אפליקטיבי( המונה כ- 1% מאנשי הפיתוח. מנהל תחום הקשור לפיתוח בארגון פיננסי אחר סיפר איך זה נראה מהצד השני: הוא תמיד חיי בתחושה שהמפתחים נמצאים במעין "אקווריום" ואין להם יכולת להרים את הראש ולראות מה קורה בחוץ. גם הוא מרגיש שהרגולציה עושה הרבה סדר ומביאה לייעול של התהליכים. מבחינתו שיתוף הפעולה בין אבטחת המידע לפיתוח הוא טוב "ברגע שאנשי האבטחה מעורבים אין מראשית התהליך". משתתף נוסף מארגון זה )גם הוא מתחום הקשור לפיתוח( סיפר על נקודות המגע העיקריות בין אנשי הפיתוח לאנשי אבטחת המידע. לדבריו, כמעט ויכוחים בכל הקשור לפונקציונליות הסופית ולאיפיון המערכת. רוב הויכוחים והחיכוכים הם על השאלה "איך להגיע לאותה פונקציונליות?" כלומר לגבי תהליכי הפיתוח עצמם. אנשי הפיתוח בארגון זה מכירים בצורך לשמור על סטנדרטים של פיתוח מאובטח, אך את הדרך לשם הם לא תמיד רואים עין בעין עם אנשי האבטחה. לדוגמא: האם המפתחים רשאים לראות נתונים כאלה ואחרים תוך כדי תהליך הפיתוח? האם בכלל ניתן לבצע פיתוח בלי לראות את הנתונים? כחלק מהדיון בנקודה זו שאלנו מה לגבי ערבול או מיסוך של נתוני ייצור במעבר לסביבות פיתוח ובדיקות? התגובות סביב השולחן היו מאוד צוננות ועושה רושם שהניסיון עם פתרונות 7 לערבול נתונים לא היה טוב על פי נסיונם של משתתפים אלה. כמובן שלא בכל הארגונים קיימת תמיד אידאליה. נציג מתחום הפיתוח בארגון פיננסי מספר כי בעבר הוא "סבל מאוד" מהתערבות של אנשי אבטחת המידע בתהליכי הפיתוח שלו. היום הם נמצאים בסטאטוס יותר רגוע ומחפשים את השפה המשותפת בין הגופים. ברור לו כי גם כאיש פיתוח כדאי לשלב את אנשי אבטחת המידע כמה שיותר מוקדם בתוך התהליך כדי להמנע מחיכוכים ומריבות בהמשך. משתתף זה העלה נקודה מעניינת מאוד סביב המקצועיות של הגורמים השונים: מההתרשמות שלו קיים פער ידע בין אנשי הפיתוח לאנשי אבטחת המידע. שקשה למפתחים להסביר לאבטחת כניסה של פרוייקט פיתוח מסויים לטכנולוגיות כמו יש נושאים מידע והבדלי הידע האלה מביאים לחיכוכים. לדוגמא: AJAX או jquery אבטחת מידע לא תמיד יש ידע מספיק כדי לחפש כשלים במערכות כאלה. "דיי סגורים" ולאיש אנשי אבטחת 7 אין בהערה זו לחוות דעה, אלא להעביר את התחושה שהתקבלה סביב השולחן. עושה רושם כי הבעיות שהוצגו על ידי חלק מהמשתתפים בהקשר של מערכות לערבול נתונים אינן שונות גם מדיונים קודמים בעניין: עקיבות של נתונים בחיבור של מספר מערכות ובסיסי נתונים וקושי באינטגרציה.

7 המידע מנסים לעתים לנתב את הפיתוח לטכנולוגיות מוכרות להם כדי שיוכלו להכיר טוב יותר את תהליכי הפיתוח ולנטר אותם. פרוייקטים בעייתים במיוחד הם פרוייקטי Main-.Frame תחום ה MF מתאפיין ברמת מומחיות גבוהה מאוד וידע אשר לא תמיד קיים ברשותם של אנשי אבטחת המידע. פיקוח על פרוייקטים אלה מאוד קשה באופן טבעי אם כי נחשב ברמת סיכון נמוכה יחסית. נציג תחום אבטחת המידע בארגון זה, האחראי בין השאר גם על היבטי הפיתוח המאובטח מספר כי התחום גדל מאוד בשנים האחרונות. הנהלים בארגון מדברים על שילוב אבטחת המידע בשלב הייזום של כל פרוייקט רלוונטי והם רואים התקדמות גדולה בשנים האחרונות. משתתף זה סיפר כי כל עוד הפרוייקט הוא פרוייקט מתוכנן, השילוב של אבטחת המידע נעשה בצורה טובה יותר וכי בפרוייקטים חשובים קיימת ועדת היגוי שחברים בה כל הגורמים הרלוונטים. הבעיות מתחילות בפרוייקטים לא מתוכננים אשר לא תמיד מגיעים לידיעת גוף אבטחת המידע. נציג ארגון פיננסי נוסף העלה את הקושי הזה כקושי מרכזי בליווי פרוייקטים מצד אבטחת המידע. בארגון זה יש קושי בהגדרה של מה זה בדיוק "פרוייקט". במקרים שלא מוגדר "פרוייקט" אין אבטחת מידע מתחילת התהליך ומבחינתם של אנשי הפיתוח המיזם "סובל" פחות מבירוקרטיות. דוגמא לכך היא שינוי מסויים שהתבקש במערכת מסויימת בארגון. כחלק מהשינוי ניתנו הרשאות גישה לנתונים רגישים. בגלל שהשינוי לא הוגדר "פרוייקט" הוא חמק מעיניהם של אנשי אבטחת המידע והם גילו את השינוי רק בדיעבד. ואכן, במחקר שערכה חברת STKI לגבי נוהלי פיתוח בארגוני IT 8 עלה שישנו אחוז מכובד על פעילויות שאינו מתוכנן )אינו הופיע בתוכנית השנתית(: 8

8 Regulation 15% Unplanned Requests 25% Planned Projects 60% באופן כללי עושה רושם שמנהלי אבטחת המידע לא תמיד מודעים לכל הפרוייקטים החדשים בארגונם ומגלים את חלקם בשלבים מאוחרים יחסית. בבדיקה בקרב אנשי אבטחת המידע בארגונים התגלה כי אף אחד מהמשתתפים לא היה מוכן להצהיר כי הוא או נציג אחר של גוף אבטחת המידע בארגונו מכיר את כל הפרוייקטים שדורשים בקרה וליווי של צוות אבטחת המידע כבר בשלבים הראשונים של הפרוייקט. הצהרה דומה לא נשמעה גם עבור פרוייקטים מתקדמים יותר. מאיזה שלב בפרוייקט חדש מעורבים אנשי אבטחת המידע? ברב הפרוייקטים הרלוונטים משלב הייזום 43% ישנם פרוייקטים רלוונטים שלא הייתי מודע לקיומם עד שלב מתקדם מאוד 29% ברב הפרוייקטים הרלוונטים משלב הפיתוח\עיצוב \בניה 28%

9 מהתרשים למעלה עולה כי ברוב הפרוייקטים הרלוונטים, צוות אבטחת המידע מכיר ומלווה את הפרוייקט. עם זאת, חשוב לשים לב לממצא מאוד מדאיג, לפיו 29% ממנהלי אבטחת המידע התוודו כי ישנם פרוייקטים "שנעלמו מהרדאר" שלהם עד שלב מתקדם מאוד )הכוונה היא לפרוייקטים שבדיעבד היה צורך ללוותם מהתחלה(. משתתף מארגון ממשלתי מסויים סיפר כי הוא אומנם מייצג את גוף הפיתוח, אך למעשה עוסק לאחרונה באבטחת מידע כחלק מעיסוקו בפיתוח. מההתרשמות שלו עולה כי יש שיתוף פעולה טוב בין הגורמים. משתתף אחר מתחום הפיתוח סיפר כי בהקשר זה כי הוא ומנהל אבטחת המידע יושבים באותו חדר. סידור זה, כשלעצמו, יכול למנוע רבים מהחיכוכים בין הגופים ולקדם שיתוף פעולה פורה יותר. שיפור תהליכי עבודה שינויים ארגוניים מהווים מנוף לבחינה מחדש גם של יחסי הפיתוח עם אבטחת המידע. ממצא זה עולה מדבריהם של חלק מהמשתתפים בדיון: משתתף מתחום אבטחת המידע בארגון ממשלתי סיפר כי בארגונו לא תמיד עירבו את אנשי אבטחת המידע בפרוייקטים חדשים. כיום מתבצע מהלך גדול בארגון של הסבה מסביבת פיתוח אחת לאחרת והוא בא ללמוד ולנסות לקדם שיפור בעבודה המשותפת עם אנשי הפיתוח. בארגון נוסף יש שינוי ביחסי העבודה בין הפיתוח לאבטחת מידע בעקבות שינוי ארגוני. לפני השינוי, אגף הפיתוח וממונה אבטחת המידע לא דיווחו לאותו מנהל. כיום שניהם נמצאים מתחת למנהל מערכות המידע והוא מעורב ברוב הפרוייקטים החשובים. השיקול האם לשלב את אבטחת המידע בפרוייקט מסויים היא שלו והחיים הרבה יותר פשוטים. אחד המשתתפים סיפר על הדרך בה הוא "מזכיר" למפתחים את גוף אבטחת המידע בפרוייקטים: הוא נכנס עם ה PMO בארגון לגאנט והכניס תזכורות ודגלים של פניה לאבטחת מידע בשלבים שנראו לו חשובים, במיוחד בתחילת פרוייקט. כך אחוז מאוד גבוה מהפרוייקטים החדשים מגיע לידיעתו בזמן. הערה חשובה נוספת בהקשר הזה מדברת על הראיה העסקית שיכולה להיות לאיש אבטחת המידע. חלק מהותי משלב האיפיון זה הסתכלות על הפונקציונליות של המערכת. יש חשיבות אבטחתית רבה אם מערכת מסויימת היא פנימית היום ומחר נחשוף אותה לאינטרנט. אך עם זאת, חשיבה מראש לגבי תכנון מערכת כזו ועצם הצורך בחשיפה שלה יכולה לחסוך בעיות בהמשך הדרך. המשתתף שהעלה את ההערה אומר כי לאיש אבטחת המידע חייבת להיות אוריאנטציה עסקית בכל החלטה אבטחתית שלו. דוגמא לכך היא המקרה הבא: מערכת

10 CRM בארגון מסויים שהמתכננים רצו להוסיף בה צרופה לשלוח ללקוח במקרים מסויימים. איש אבטחת המידע העלה את הבעייתיות האבטחתית בהוספת צרופה ושאל את מבקש הבקשה מה הצורך העסקי בצרופה כזו ומה היא משרתת? מתברר שלא היה צורך עסקי לבקשה והיא היתה תוצאה של בקשה מהעבר שכבר לא היה בה צורך. ההצעה ירדה מסדר היום. הפיתוח הוא של השותפים\מוצרים, אבטחת המידע של הארגון בארגון מסויים איש אבטחת המידע המשתתף בדיון ציין כי במקור הוא היה איש פיתוח וכי הוא מכיר מצויין את אופן הפעולה של "הצד השני". כחלק משיפור העבודה בארגון יש כוונה לשלב מתודולוגיות ונהלים של פיתוח מאובטח, אשר עד היום טרם מומשו. מארגון השני הנציג בגוף הזה יש דגש זה מגיע מגוף רוחבי הקשור לניהול פרוייקטים. נציג גוף זה סיפר כי חזק על בטיחות השירותים והמוצרים ולא על אבטחת מידע. נושא אבטחת המידע צריך לקבל יותר דגש ללא ספק. בגלל אופי העבודה והממשק הרב עם גורמי חוץ, קשה לא פעם להגדיר מהו לאכוף אותו. רף המינימום נקודה נוספת קשורה לבחירת הטכנולוגיה זה, נגזרת מאופי הפרוייקט והגדרות הלקוח ולא משיקולי אבטחת )במידה ואלה לא הוגדרו מראש על ידי הלקוח(. בכל הקשור לאבטחת מידע ואיך בכלל ניתן בכל פרוייקט ארגוני וזו, על פי נציג המידע הפנים ארגוניים בארגון גלובלי מתלבטים לא מעט איך לשמור על רמה מינימלית של אבטחת מידע בחלקים המגיעים משותפי פיתוח ומוצרים משלימים. כל עוד הפיתוח נעשה "בבית" אין בעיה. אבל במידה ומדובר בפיתרון שמקורו בחברה חיצונית לא תמיד ניתן לבקש מהחברה לראות את הקוד ולנתח אותו. לסוגייה זו יש גם היבטים משפטיים ולא בטוח שניתן לעשות "הינדוס לאחור" מבחינה חוקית. דרך אחת לנסות ולפתור חלק מהבעיות היא לבצע הדרכות ולנסות כן ליצור קשר עם חלק משותפי הפיתוח. אופציות אחרות הן לבצע 9 blackbox אשר נחשבות ליקרות מאוד שכן הן צורכות זמן רב ומשאבים גדולים. בדיקות חדירות מסוג מערכות אופייניות בארגון זה מכילות כמות עצומה של שורות קוד וכדי לסרוק חלקים חשובים בהן נעשה שימוש במערכות אוטומטיות לסריקת קוד )ראו התייחסות לכלים בהמשך(. 9 בבדיקות חדירות מסוג blackbox למבצע הבדיקות אין גישה לקוד עצמו והוא נאלץ למצוא פגיעויות או חולשות בתנאים התחלתיים קרובים מאוד לאלה של גורם עויין אמיתי. בטרמינולוגיה של מבצעי בדיקות החדירות נהוגים שני ביטויים נוספים: Whitebox בה למבצע הבדיקה יש את קוד המערכת )כאילו הוא פיתח את המערכת בעצמו( ו Greybox בה למבצע הבדיקה יש חלקים מהקוד או פונקציונליות מסויימת של המערכת.

11 איש אבטחת מידע נוסף שהגיע מתחום הפיתוח מספר כי לאיש פיתוח קיימות הרבה מאוד אופציות ואפשרויות לכתוב כל מערכת או פונקציה נתונה. היצירתיות כאן מאוד חשובה ובמידה מסויימת זהו מוטיב הפוך להלך המחשבה של איש אבטחת מידע. במציאות כזו לא מפתיע למצוא הרבה בתי תוכנה קטנים עם שיטות שונות ומשונות לפיתוח אותם מוצרים. "ממש שכונה". בארגונו, המשתייך לסקטור הפיננסי, גוף אבטחת המידע נחשב לחזק יחסית וקל לו לכפות סטנדרטים ודרישות מינימום ממפתחים שותפים. משתתף זה מספר כי בעבר "ניפנפו" מערכות שלא תאמו את דרישות המינימום של הארגון. ארגון פיננסי מסויים סיפר כי המדיניות אצלם היא קניה ולא פיתוח מערכות חדשות. כדי לגדר את הסיכונים הכרוכים במערכות צד ג', כדאי לנסות לסגור כמה שיותר פרטים במעמד החוזה. לגישה זו חיסרון מסויים: לפעמים מקבלים מוצר המותאם מאוד לצרכי הארגון, מעין גרסה ייחודית ובלעדית, שקשה לקבל עליה תמיכה )גם מהספק עצמו( בהמשך הדרך. סוג אחר של בעיות רואים במערכות המפותחות לרשתות חברתיות. כיום מבוצע הפיתוח על ידי בית תוכנה קטן מאוד שהמרחק בינו לבין פיתוח במתכונת SDLC גדול מאוד. בגלל אופי הארגון והאיומים, נדרש בית תוכנה זה לעמוד בדרישות הפיתוח של.SDLC דרישה זו האריכה את זמן העליה לאוויר של קמפיינים מסויימים פי 6 מהמתוכנן )!!(. במובנים עסקיים מדובר על מחיר גבוה שהארגון שילם כדי לשמור על סטנדרטים גבוהים של אבטחת מידע. משתתף אחר מהצד של אבטחת מידע בארגון עסקי סיפר כי בארגונו יש הרבה מאוד פיתוח פנימי בארגון הן במערכות פנימיות והן במערכות בעלות ניראות אינטרנטית. ארגון זה לא כפוף לרגולציות משמעותיות והדבר מקשה מאוד על גוף אבטחת המידע. קשה לכפות תהליכי עבודה ופיתוח מאובטח והשיקולים המובילים ברוב הפרוייקטים הם שיקולי תחרות ושיקולים עסקיים. גם בארגון זה יש בעיה מאוד לא פשוטה בכל הקשור להתמודדות עם מערכות המפותחות על ידי שותפים עסקיים של הארגון. משתתף זה מספר על מספר רב של מערכות שעלו לאוויר בשילוב עם מערכות צד ג' אשר לא פותחו לפי סטנדרטים מתאימים. לחץ הזמן והרצון העסקי "להיות ראשון" מוריד בסדר העדיפויות את שיקולי האבטחה. ברוב המקרים נעשות בדיקות חדירות לאחר העליה לאוויר. במקרים מסויימים בעבר נמצאו מערכות עם לקויים וחולשות אבטחתיות ונדרשו תיקונים, אולם בשום מקרה לא ירדה מהאוויר מערכת בשל ליקויי אבטחה שנמצאו בה.

12 נאמן אבטחת מידע בגוף פיננסי מסויים קיים שיתוף פעולה טוב מאוד בין גופי הפיתוח לגוף אבטחת המידע. בגוף זה יש נכונות לשלב את צוות אבטחת המידע כבר בשלב הייזום וכן ללות פרוייקטים קיימים. נציג גוף אבטחת המידע בגוף זה מספר כי הוא נתקל בחוסר מודעות בקרב מתכנתים בארגון לנושאי אבטחת מידע וכי קשה להביא לשינוי דרמטי בנושא ללא השקעה תקציבית גדולה. אלמנט נוסף הוא השימוש בגוף QA בעל מודעות לנושאי אבטחת מידע. משתתף זה סיפר כי הם עושים שימוש בשירותי הבדיקות של חברת מטריקס, אשר מאוד מודעים לתחום אבטחת המידע. במצב אידאלי היה ראוי לשלב עובד QA יעודי לנושאי אבטחת מידע, שכן סט הבדיקות "הרגילות" שעובד QA מבצע אינן זהות לבדיקות אבטחת מידע. בארגון זה עובדים לפי מתודולוגיית SDLC בפרוייקטים חשובים ורגישים. אלמנט נוסף ומאוד חשוב לפיתוח מאובטח הוא רתימת איש פיתוח שיהווה רפרנט אבטחת מידע בתוך גוף הפיתוח. נציג גוף הפיתוח בארגון זה מהווה רפרנט אבטחת מידע. בין השאר הוא מעורב בכתיבת נהלי אבטחת המידע הקשורים לפיתוח ולסקירת קוד. נציגי גוף אבטחת מידע בארגון פיננסי סיפרו על חשיבות שיתוף הפעולה בין הפיתוח לאבטחת המידע והרחיבו על הנעשה בארגונם. "כשיש תקלה כולם חוטפים". בארוע שהיה לפני כמה שנים ובו דווח בתקשורת על תקלה אבטחתית במערכת מסויימת הוקפצו ותוזזו כל הגורמים הקשורים בארגון במשך כמה ימים רק כדי לנסות ולאתר את מקור התקלה. בדיעבד התברר שלא נגרם כלל נזק, אך העלות הכוללת של עבודת הבדיקה המיותרת עלתה הון. דוגמא זו ממחישה את הצורך בעבודה משותפת ברמה יומיומית בין הגופים השונים הקשורים לפיתוח ותחזוקת מערכות. בארגון זה ישנו דגש חזק על אמינות השירותים. דגש זה מקדם בסדר העדיפויות את כל התחום של אבטחת מידע ולכן הארגון "יכול להרשות לעצמו" מספר אנשי אבטחת מידע עם התמחות בעולם האפליקטיבי. אנשים אלה נותנים שירותי ערך מוסף לגופי הפיתוח ואף כותבים בעצמם קטעי קוד בעייתיים במידת הצורך. בארגון זה עובדים על פי מתודולוגיות SDLC על פי best practices של ארגון OWASP ופועלים על פי עקרונות CWE תקן בדיקת פגיעות במערכות. בארגון מערבים נציג של אבטחת מידע כבר מתחילת הפרוייקט. גם כאן, כמו ברוב הארגונים במשק, אין לגוף אבטחת המידע יכולת לדעת על כל הפרוייקטים החדשים כבר מתחילתם. כדי לצמצם למינימום את מספר הפרוייקטים "שנעלמים מהרדאר" של אבטחת המידע, מוגדרים נהלי עבודה לצוותי הפיתוח וניהול הפרוייקטים ועל פיהם יש לדווח לגוף האבטחה על כל פרוייקט חדש.

13 כדי להוריד את העומס ולייעל את התהליך מעורבים אנשי האבטחה בנקודות מפתח חשובות בפרוייקט: בשלב הייזום במידת הצורך, מעורבות עקרונית וראשונית, בשלב הפיתוח שהוא שלב האיפיון החלק הגדול של הפרוייקט מתן הערות של אבטחת מידע בדר"כ, אבטחת המידע פחות מעורבת. שלב הבדיקות אבטחת המידע משתלבת מחדש בבדיקות הקוד לאחר סיום מחזור הפיתוח הראשון. בשלב הבא מבוצעות בדיקות קוד אוטומטיות בעזרת כלים אוטומטיים. בשלב זה יושב איש אבטחת המידע שבוחן את הממצאים עם המתכנת ומסביר לו את הממצאים. השאיפה היא להביא להבנה ו"לגייס" אבטחתית יותר. "הופכים איש הפיתוח לנאמן אבטחת מידע". את אנשי הפיתוח לחשיבה "חשיבות הישיבה עם איש הפיתוח היא עצומה. הסקרנות הטבעית שלהם והרצון לייעל את עבודת הפיתוח במערכת הבאה מביאה לשיתוף פעולה טוב מאוד ברוב המקרים". הממצאים שעלו בשלב הבדיקות עוברים לתיעוד ומעקב במערכת לניהול סיכונים. השלב האחרון מבחינת אבטחת המידע הוא על גרסת קוד בשלה מאוד שעברה לפחות סבב שלב בדיקות החדירות )PT( QA אחד. כדי לנסות לקבל מושג על שיתוף הפעולה בין שני הגופים, שאלנו זה מיושם -שלב האם קיים בצוות ההיגוי של אבטחת מידע בארגון נציג של אגף הפיתוח. בוועדה זו נקבעים הנהלים וסדרי העבודה הרוחביים בארגון בכל הקשור ליישום מדיניות אבטחת מידע. כמו כן נקבעים שם נהלים ספיציפיים לפרוייקטים ומערכות ארגוניות חשובות. ברור, שהמצב ההפוך )נציג אבטחת מידע בישיבות בנושאי פיתוח( מתקיים. הדרך לראות עד כמה עובדים שני הגופים בשיתוף פעולה טוב היא, בין השאר, לבחון את המעורבות השוטפת של אנשי הפיתוח בוועדת ההיגוי של אבטחת המידע. התפלגות התשובות במפגש מתוארת בתרשים הבא: קיים מגיע לישיבות באופן קבוע ויש שת"פ פורה 20% האם קיים אצלכם נציג אגף הפיתוח בצוות ההיגוי הכללי של אבטחת המידע? לא קיים באופן קבוע בצוות ההיגוי מגיע על פי צורך ויש שת"פ פורה 40% אחר\לא קיים 27% קיים לא תמיד מגיע לישיבות 13%

14 מהתרשים ניתן ללמוד כי ב 60% מהארגונים קיימת נוכחות מספקת של נציגי הפיתוח בפורום ההיגוי של אבטחת המידע. ב 40% מהארגונים אין נוכחות מספקת של נציגי הפיתוח בוועדת ההיגוי, מצב המרמז, אולי, על העדר שיתוף פעולה מספיק בין הגופים. תקציב אבטחת המידע בפיתוח לאורך כל הדיון נשאלו המשתתפים לגבי נושא תיקצוב אבטחת המידע בכל הקשור למחזור הפיתוח של מערכות חדשות. במיוחד עניין אותנו לדעת האם התקציב הוא חלק מתקציב הפרוייקט, חלק מתקציב אבטחת המידע בארגון או שלא מוגדר תקציב ספציפי לנושא? מבדיקה בקרב הארגונים שהשתתפו בדיון עולה כי ב 48% מהמקרים, תקציב אבטחת המידע מגולם בתוך תקציב הפרוייקט )כלומר העלות של הטיפול באבטחת מידע הנה מתוך תקציב הפיתוח, למרות שברב המקרים אין סעיף תקציבי ספציפי לעניין(, ב 38% מהמקרים מדובר על חלק מתקציב גוף אבטחת המידע ואילו ב 14% מהמקרים אין תקציב מוגדר לנושא אבטחת המידע בתהליך הפיתוח או שנמצא תקציב ממקורות אחרים. הערה: מכיוון שברוב הארגונים אין סעיף נפרד של תקצוב אבטחת מידע בתוך הפרוייקט, מדובר על הערכה בלבד. הממצאים מסוכמים בתרשים הבא: איך מתוקצב נושא אבטחת המידע בכל הקשור לפרוייקט חדש בארגון? לא מוגדר תקציב ספציפי \ אחר 14% חלק מתקציב הפרוייקט 48% חלק מתקציב אבטחת המידע בארגון 38% שאלה אחרת שעלתה בפורום היא מהו החלק היחסי המוגדר לנושאי אבטחת מידע מתוך כלל תקציב הפרוייקטים בארגון. סעיף זה חולק למספר סעיפים עיקריים: פרוייקטים חדשים ופרוייקטים קיימים. כמו כן התבקשו המשתתפים לבצע את האומדן לכל סביבה מהסביבות

15 הבאות: פרוייקטי,Main-Frame פרוייקטים במערכות פתוחות פנימיות ופרוייקטים במערכות פתוחות הפונות לסביבת האינטרנט. הממצאים מרוכזים בטבלה הבאה: אחוז ההוצאה על אבטחת מידע מתוך סך התקציב של פרוייקט נתון פרוייקט בסביבת MF פרוייקט במערכות פנימיות\ אינטראנט בסביבה הפתוחה פרוייקט במערכות אינטרנט בפרוייקטים חדשים 1.33% 5.45% 9.33% בפרוייקטים קיימים )תחזוקה( 1.5% 4.15% 7.25% השונות בתשובות הייתה גבוהה יחסית וניתן לראות שישנם ארגונים בהם אחוז ההוצאה על אבטחת מידע מתוך סך תקציב הפרוייקט יכול לנוע בין 0% בפרוייקטי MF ועד 40% או 50% באפליקציות אינטרנט רגישות. חלק מהמשתתפים ציינו כי תשומות אבטחת המידע לפרוייקט נגזרות מעוד פרמטרים פרט לאופי הסביבה: בארגון פיננסי מסויים סיפרו על חלוקת משאבים לפי לפי סיכון המערכת כפי שזה הוגדר במערכת הארגונית לניהול סיכונים. שיקול נוסף לקביעת היקף התשומות הוא מידת ההכרות עם המערכת המפותחת. מערכות לא מוכרות אשר דורשות למידה על ידי צוות אבטחת המידע והפיתוח יחייבו תקציב נוסף. כאלה למשל הן מערכות חדשות בעולם ה.mobile דוגמאות לטכנולוגיות בשימוש הדיון על טכנולוגיות וכלים בשימוש בארגונים ארך כ 20 דקות בלבד. עושה רושם שיש בעיות דחופות יותר בתחום מהטכנולוגיה עצמה. מבין הפתרונות שכן זכו לאיזכור חיובי ניתן למנות את Checkmarx אשר נחשבים לפיתרון מוכר וטוב לתחום בדיקות הקוד האוטומטיות. הביקורות ממי שציין את המוצר הזה היו טובות מאוד.

16 פיתרון אחר הוא Versafe סויטה של פתרונות הכוללים, בין השאר, יכולות לבדיקת קוד ו Bugsec אבטחתי. המוצר פותח על ידי המייסדים של חברת הייעוץ הישראלית QA המתמחה בבדיקות קוד ומבדקי חדירות. מוצר אחר שהוזכר הוא מוצר בשם Seeker שפותח על ידי מייסדי חברת Hacktics אשר גם היא מתמחה בביצוע מבדקי חדירות למערכות וסקרי אבטחה. כאן מדובר בפיתרון המריץ בחלק מהמקרים התקפות מדומות על מערכות בפיתוח מתוך כוונה לאתר פגיעויות בהן. הפיתרון יודע להקליט ולבצע תיחקור של המתקפה ולהשתלב בצורה יפה בתהליך הלמידה של פיתוח המערכת ולשפר את אופן הפיתוח. פיתרון מעניין שהוזכר בהקשר של אכיפת מדיניות אבטחת מידע מול פתרונות open source ויישומים שפותחו על ידי גורמים חוץ ארגוניים, בייחוד בהקשר של איתור קוד פתוח ובחינת המשמעויות של סוג הרישוי של קוד זה, הוא של.Blackduck המשתתף שציין את הפיתרון הזה סיפר כי הוא מסוגל לסייע בהלבנה של החלקים הבעייתים בקוד המקור. בארגון זה מיושם הכלי בתצורת SAAS פעם בשנה משיקולי עלות. במפגש הוזכרו בקצרה כמה כלים נוספים כגון Fortify,HP Dynamic Web Analyzer ואחרים. אבטחת מידע באקדמיה אחד הויכוחים הגדולים כיום בפורום הישראלי לאבטחת מידע נסוב סביב שאלת האקדמיזציה של מקצוע אבטחת המידע. במישור האקדמי אין כיום למעשה מסגרת המסדירה את הרקע הנדרש לפעילותו של מנהל אבטחת המידע בארגון, למעט הסמכות בינלאומיות רלוונטיות. כמו כן בשום מסגרת אקדמית לא מוסדר הרקע האבטחתי הנדרש מאנשי מקצוע העוסקים בפעילות הקשורה או משיקה להיבטי אבטחת המידע בארגון )אנשי פיתוח, אנשי סיסטם, מנתחי מערכות וכן הלאה(. את התוצאה ניתן לראות בחלק מהסעיפים הקודמים במסמך זה: חוסר הבנה ורקע מקצועי של אנשי האבטחה והפיתוח, אחד בתחום העיסוק של השני. על מה הויכוח? חלק מהאנשי אבטחת המידע בפורום טוענים כי יש ללמד לימודי אבטחת מידע באופן פורמלי כמקצוע העומד בפני עצמו באקדמיה. מסיים התואר יזכה באישור אקדמי ויתרון בעיסוק כאיש אבטחת מידע, תוך קבלת רקע מקצועי במגוון היבטים אחרים של עולם המיחשוב. הקבוצה השניה גורסת כי יש לשלב את לימודי אבטחת המידע כחלק מתוכנית לימודים סטנדרטית של מקצועות המחשב. ניתן לעשות זאת במספר קורסים בסיסיים או כהתמחות

17 )אשר תאפשר למחזיקים בה לקבל הסמכה מקצועית כאיש אבטחת המידע(. כך גם יובטח הרקע הטכני הדרוש לאיש אבטחת מידע בארגון והרקע הנחוץ בנושאי אבטחה לשאר אנשי מקצועות המחשב. מכל מקום, הסדרת נושא ההכשרה והרקע הטכני יקלו מאוד גם בתפר הכל כך בעייתי בין אנשי אבטחת המידע לגורמים אחרים בארגון ויקדמו את העבודה המשותפת לטובת הארגון. טיפים והמלצות לשיפור יחסי אבטחת המידע/פיתוח בדיון עלו מספר טיפים לשיפור אבטחת המידע בהקשר של פיתוח: שבו ודברו אחד עם השני - המידע יושבים באותו חדר. משתתף מתחום הפיתוח דיאלוג הוא המפתח להתייעלות. סיפר כי הוא ומנהל אבטחת מהבעיות והחיכוכים יכולים להמנע אם שני הצדדים ידברו אחד עם השני. שתפו פעולה מהרגע הראשון ללא ספק, רבות לאורך כל הדיון חוזר מסר זה משני המחנות: יידוע גוף אבטחת המידע ושילובו בתחילת כל פרוייקט מקילים מאוד על המשך התהליך ומורידים עלויות פיתוח. אימוץ סטנדרטים בעקבות רגולציות לפיתוח מאובטח. PCI משמעותית את המודעות לנושא. -רגולציה באופן כללי עוזרת לאבטחה ועוזרת היא דוגמא טובה מאוד לרגולציה אשר מעלה בצורה "אנחנו על המפה" -אחד המשתתפים סיפר על הדרך בה הוא "מזכיר" למפתחים את גוף אבטחת המידע בפרוייקטים: הוא נכנס עם ה PMO בארגון לתרשים הגאנט והכניס תזכורות ודגלים של פניה לאבטחת מידע בשלבים שנראו לו חשובים, במיוחד בתחילת פרוייקט. כך אחוז מאוד גבוה מהפרוייקטים החדשים מגיע לידיעתו בזמן. "אמץ" איש פיתוח הפיתוח. לדוגמא: נציג גוף -רתימת איש פיתוח שיהווה רפרנט אבטחת מידע בתוך גוף פיתוח בארגון מסויים מהווה רפרנט אבטחת מידע. בין השאר הוא מעורב בכתיבת נהלי אבטחת המידע הקשורים לפיתוח ולסקירת קוד. החשיבות בגיוס של איש הפיתוח יכולה לתרום רבות להידוק היחסים בין הצדדים. הכנס גורם מקצועי לעובי הקורה והוספת הדרכות הכנסת יעוץ מקצועי לארגון, כזה המכיר מצויין את המניעים והאתגרים של שני הצדדים יוכל )"להרגיע" אבטחת גוף את המידע הצדדים בין לגשר על ידי העלאת הידע המקצועי שלו בתחום הפיתוח המאובטח ו"להרגיע" את גוף הפיתוח על ידי מתן עצות פרקטיות לשיפור תהליך הפיתוח תוך מתן תשומת לב לאבטחה(.

18 נספח מיוחד התייחסות ספקים לנאמר במפגש התייחסות חברת F5 )איש קשר: גד אלקין: ) G.Elkin@F5.com " I think that their approach is good but is missing a key function - The last round of checks should be done on the production system since the code on production is many times different than the code on the test environment. Another thing is to leverage network devices for things that can be developed (auth/auth) Last thing is that if you have a WAF, you could mitigate vulnerabilities fast without taking dev resources, let the dev work out the fixing in their own time, this is an example where the security team can help dev reach milestones." Also relevant: ) התייחסות חברת IBM )אשת קשר: אליה ויינברגר: e_weinberger@il.ibm.com אחת הבעיות שאיתה צריך מנהל אבטחת המידע להתמודד היא התראות שווא,דבר שגוזל לעיתים זמן רב בלנסות ולאמת אותן. אחת הדרכים לצמצום התראות אלו וקבלת תוצאות אמת הוא שילוב )קורלציה( של אנליזה סטטית ואנליזה דינמית. שני הפתרונות יכולים לרוץ בנפרד ולספק תוצאות על פגיעויות, כאשר אנליזה סטטית סורקת את הקוד עצמו ומחפשת מפגעים במעבר של המידע בין המתודות השונות. אנליזה דינמית מדמה התקפה של האקר אל מול האתר כאשר גם תשתיות האתר כגון בסיס הנתונים application, web חשופים להתקפה.

19 אחת מנקודות התורפה של שתי השיטות הם ממצאי השווא עליהם שוקדים החוקרים והמפתחים של המוצרים בנסיון לצמצם אותם. השיטה להתגבר על הבעיה היא קורלציה )התאמה( של הממצאים משתי הכלים,כאשר לוקחים דוח של סריקה סטטית מעל סריקה דינמית ומבצעים קורלציה ניתן לוודא כי הממצאים אכן מתריעים על מפגעים אמתיים ובכך להפחית משמעותית את התראות השווא אחת מהחברות שמספקת פיתרון כזה היא IBM עם כלים ממשפחת.Appscan התייחסות חברת Matrix )איש קשר: ארי רוזנבאום: ) ariro@matrix.co.il עדכוני תוכנה ושינוי קונפיגורציה בשרתים פותחים פרצות חדשות. פיתוח קוד מאובטח לא מכיל הגנה מפני גניבת זהות. אמצעים: Phishing Pharming Key Logging Machine Trojan Infection :Application Access Control יכולת לחסום גישת משתמש שאין ברשותו הגנה מפני גניבת זהות, השתלטות על תחנה, הגנה מפני Key Logger וכדומה. יכולת לחסום פעולות בהרשאות מסוימות. :Application Restricted Zone - ARZ הגדרת חלק מבודד באפליקציה שלא ניתן לגשת אליו ממקורות חיצוניים )בדרך כלל החלק של האפליקציה שאחרי הLogin (. סטנדרטים מתקדמים מסוג HTML5 ופגיעויות בדפדפנים מאפשרים גניבת מידע אישי, גניבת זהות, שליחת פקודות לאפליקציה וכדומה. מאפשר לארגון: שימוש בטכנולוגיה של Comitari לקבל דיווחים ב- Real Time על פרצות אמתיות באפליקציה שנוסו על משתמשי האפליקציה. הגנה מלאה מפני גניבת זהות. דיווח על ניסיונות תקיפה וגניבת זהות של משתמשי האפליקציה. Client Side סגירת מעגל האבטחה עם תוכנת הגנה ב מתן שכבת הגנה המספקת אבטחה לכל האפליקציות העושות שימוש ב browser וחוסכת את הצורך בפיתוח ייעודי לכל מערכת חטיבת מוצרי התוכנה במטריקס מייצגת את פתרון האבטחה. Comitari התייחסות חברת Ness )אשת קשר: דגנית בודק: ) Dganit.Bodek@ness.com כיום כאשר המודעות ההולכת וגוברת בכל הקשור לאבטחת המידע הרגיש בארגון ביחד עם אימוץ סטנדרטים,רגולציה,תקנים, וחוקים בנושא זה, ארגונים נדרשים כיום להעניק משנה דגש על נושאי אבטחת המידע ובדגש מידע בעל רגישות גבוהה. ארגונים משקיעים משאבים רבים בהגנה על המידע בפני גורמי חוץ אך נוטים להשאיר פרצה אל מול גורמי הפנים בארגון,ובדגש סביבות פיתוח בלתי מאובטחות, כאשר כלי ההגנה הסטנדרטים יעניקו הגנה מפני משתמשים בלתי מורשים, נדרש

20 פתרון שלם וצמצום משמעותי של סיכונים ברמת אבטחת המידע גם אל מול המשתמשים מבית )המורשים(. : ActiveBase Security פתרון תוכנה המאפשר מעקב והפעלת מדיניות אבטחה אקטיבית ובקרות גישה לבסיסי הנתונים. הפתרון מאפשר למנהל המערכת להפעיל חוקי הגנה ומיסוך נתונים דינאמי של נתונים רגישים, מידור בקשות המשתמשים בזמן אמת, יחד עם שמירת מעקב ותיעוד מפורט על כלל השאילתות )ואו על ביצוע פעולות ספציפיות( תוך מתן חיווי למשתמש והתראות לממונה\מנהל אחראי במצבי חריגה. המערכת פועלת באינטגרציה מלאה מול מערכת ניהול המשתמשים של הארגון )LDAP( ומאפשרת זיהוי ומידור לפי שיוך המשתמש לקבוצות משתמשים ב ActiveDirectory,סוגי אפליקציות, זיהוי משתמש אפליקטיבי, חסימת פקודות אסורות למשתמש אל מול בסיס הנתונים, ועוד... בנוסף, הנתונים הרגישים ימוסכו בצורה דינמית עד לרמת השדה על פי ההרשאות שיוגדרו לכל משתמש. לצורך הדוגמא : לעובדים בסביבת הפיתוח כיום קיימת גישה חופשית למאגרי הנתונים של הארגון, עובדים אלו מסוגלים לצפות במידע מסווג כמו : נתוני שכר, ססמאות,מספרי כרטיסי אשראי, מידע רפואי, וכו', כמו כן, מסוגלים לייצא מאגרי נתונים )למשל רשימת לקוחות החברה\כרטיסי אשראי( מחוץ לארגון אף בהיבטים הפליליים. סביבה מוגנת ע"י ActiveBase לא תאפשר הצגת הנתונים הרגישים, שימוסכו,יעורבלו,יוסתרו מפני הגורם הפנימי שלא רשאי לצפות, וכמו כן תוגבל שליפת כמות הרשומות לפי הצורך, ולהיות מדווחת ומתועדת לצורך בקרה ובדיקה עתידית. מערכת ActiveBase מותקנת במהירות ובקלות כאשר התקשורת אל בסיס הנתונים עוברת דרכו באופן שקוף לאפליקציה ולבסיס הנתונים, ואינו דורש שינוי באפליקציה, או כל שינוי תשתיתי, ומעניק הגנה מיידית על עשרות אפליקציות ובסיסי נתונים בהתקנה בודדה. התייחסות חברת Tescom )אשת קשר: אתי דביר: ) Eti.Dvir@Tescom-intl.com לדברי ניר לוי, נשיא קבוצת Tescom אבטחת מידע ואבטחת איכות הינה התמחות העומדת בפני עצמה, אשר מהווה תשתית חיונית ונדרשת במרבית המגזרים ובארגונים בכל סדר גודל. חברת טסקום פעילה בתחום זה למעלה מ- 20 שנה, כיום ניכרת פתיחות והבנה בקרב מקבלי ההחלטות לנושא אבטחת המידע והאיכות, כמו גם נכונות להשקיע בכך את המשאבים הנחוצים. " המודעות בקרב לקוחות לחיוניות אבטחת מידע ואבטחת איכות החל משלב הייזום ועד לשלבי ההשקה/"עליה לאוויר" כולל הופכים יותר ויותר למובנים בתוך התהליכים, ואני מברך על כך.

21 אבטחת המידע כמו גם אבטחת האיכות נדרשים ברבדים השונים בתהליכים הארגוניים: החל מניתוב אינפורמציה פנימית דרך הקצאת הרשאות למשתמשים ויצירת הגנה על חומרים פרטיים וכלה במניעת איומים חיצוניים, חדירות ופריצות, אשר מדווחים חדשות לבקרים. אבטחת מידע ואבטחת איכות מייצגות את האינטרס הארגוני לבקרה, אכיפה והתנהלות עקבית על פי אבני הייסוד של הפרויקט, תוך עמידה בתנאי איכות, תקני רגולציות שונים ובמסגרת הפרויקטאלית והתוכנית העסקית.